-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add git hash and tags for versioning #839
Conversation
* create all git related variables before importing configs to make it possible to use them in the board configs (e.g. for heads title) * add tags, short hash and branch information * export git tag to use it in system info as well * always create a copy of coreboot.rom containing tag and hash
This PR is not doing meaningful things in the CI. I may have a second look next week. Otherwise I might just close the PR. |
@alex-nitrokey there is a need to rethink deeply the versioning scheme of heads since fwupd has landed and requires such change in the thinking of versions. Versioning would require board name and tag names minimally. The idea here would be to reintegrate git tags so we try to follow coreboot releases. |
Goal would be to arrive to something like this with board version and maybe the timestamp of the tag? |
Glad to hear that there are changes on the way anyway! I try to have a look at the fwupd stuff these days. Thanks for letting me know! |
@@ -83,6 +83,7 @@ $(build)/$(coreboot_dir)/.build: \ | |||
$(build)/$(BOARD)/coreboot.rom: $(build)/$(coreboot_dir)/.build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something for a follow-on: coreboot.rom
isn't the most useful output name, something like Heads-<board>-<tag>.rom
would be far better. When building for a half dozen+ boards, having to rename manually to something useful after every build becomes very tiresome.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Until now I only added heads-
to the copy of coreboot.rom
. If I rename the coreboot.rom
I need to change the CI files and maybe other things too, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alex-nitrokey : CircleCI backups the content of the build dir altogether, while gitlabci is currently foo bar, whiule the same logic used to CircleCI (backup build dir instead of individual files) should be taken anyway.
@alex-nitrokey whenever ready, please rebase on master to trigger a build. |
@tlaurion I am sorry for the delay. I am a bit confused now. Do you like to have a versioning based on this PR and change to another one later on? Because you first posts sounded more like this approach would not fit the planned layouts and this PR is useless for heads therefore. |
@alex-nitrokey : Yes. I think it should be cleaner and the name of the builds should talk for themselves. Didn't review this PR yet, but the idea would be to have tags accociated with github future releases, for which versions could be evaluated by the OS (fwupd). Suggestion from FWUPD PR is to change current coreboot
|
@alex-nitrokey : had review the artifacts produced https://app.circleci.com/pipelines/github/Nitrokey/heads/123/workflows/4aade83f-1c1e-4c8a-bd04-c5b49bcbf21e/jobs/129/artifacts:
The idea here would be that the artifacts would be named after their board names |
|
@Asiderr Does it look fine from the LVFS perspective? |
@alex-nitrokey, @MrChromebox @macpijan @Asiderr https://github.com/osresearch/heads/search?q=CONFIG_LOCALVERSION%3D%22heads%22&type=code I have no answer. |
@tlaurion perhaps, in the coreboot makefile, after copying the board coreboot config to |
@tlaurion @macpijan @MrChromebox @alex-nitrokey Versioning looks fine from the LVFS perspective. As @tlaurion mentioned, the main thing is to pass the current version to the Qubes OS to make it available for fwupd. @MrChromebox approach seems to be correct. |
@alex-nitrokey @MrChromebox https://app.circleci.com/pipelines/github/MrChromebox/heads/25/workflows/0f5254de-a777-4f27-b129-693cc304bf4e/jobs/27 fails for x230-flash board, but the naming scheme of sucessfully build librem_mini looks like Once all output boards are confirmed to be clean, please decide on the way you want this to be merged upstream. |
Is that superseded by #859 @alex-nitrokey ? I think so |
The reasoning behind this small set of changes is to make versioning and referencing more easy. I do not know if this is desired, but for example having the builds locally with hash instead of overwriting every build is nice to have imho.
Please have a look if heads can use anything of that. :)